Communication system and method providing a mode selection procedure

ABSTRACT

A method and a communication system which includes a first network element, e.g. portable terminal, connectable to a second network element. One of selectable modes is used for communication. A network element is adapted to perform a mode selection procedure for selecting the same mode for bidirectional communication between the network elements. The mode selection ensures the use of one and the same mode in uplink and downlink direction and thus enables e.g. IP telephony in UMTS using SIP protocol. The invention provides for facilitating a VoIP communication session by way of a radio link with a mobile station. The mobile station forms a QoS (Quality of Service) information element for communication to a radio access network portion. The QoS information element is indicating whether to remove packet header information of the data packets to be communicated upon the radio link pursuant to the communication session.

FIELD AND BACKGROUND OF THE INVENTION

The present invention relates to a communication system adapted toperform a mode selection by selecting or negotiating the mode to beused. Furthermore, the invention relates to a method to be performed insuch a communication system, and to a network element capable of modeselection.

Advancements in digital communication techniques have permittedincreased data transmission rates and introduction of new types ofcommunication services. When digital communication techniques areutilized, data which is to be communicated is digitized into digitalform, and sometimes formatted into data packets. The data packets arecommunicated, either individually, or in groups, to a destination. Oncereceived at the destination, the packets are concatenated together torecreate the informational content of the data of which the data packetsare formed.

Radio communication systems are exemplary of communication systems whichhave benefited from advancements in communication technologies and inwhich digital communication techniques are increasingly utilized. Acellular communication system is an exemplary radio communicationsystem. And, various standards have been promulgated pursuant to whichdifferent types of cellular communication systems have been constructed.Additional standard specifications continue to be promulgated relatingboth to improvements to existing cellular communication systems as wellas new constructions of cellular communication systems. Standardsrelating to so-called, third-generation, cellular communication systemsare presently being promulgated. Standards relating to the 3G (thirdgeneration) GSM/EDGE (Global System for Mobile Communications/EnhancedData for Global Evolution) system, for instance are being promulgated.

In packet switched communications, data to be communicated is formattedinto packets, and the data packets are communicated at discreteintervals. Because the data can be communicated at discrete intervals,the communication resources, such as the bandwidth available upon theradio links formed between mobile stations and network infrastructure ofthe system, can be utilized more efficiently.

Packet-switched communications in which communications are effectuatedby the communication of data packets include voice communications. Whenthe data packets are formatted pursuant to IP (Internet Protocol)protocols, the resultant communication service is sometimes referred toas VoIP (Voice over Internet Protocol). As with other types of voicecommunication services, VoIP is time sensitive in that the data formingthe VoIP data packets must be timely communicated to maintain anacceptable communication quality level.

The data packets are typically formatted pursuant to conventionalstandards. Each data packet is typically formatted to include a headerportion and a payload portion. The payload portion is formed of the datawhich is to be communicated to effectuate the communication service. Ina VoIP service, the voice data is contained in the payload portion ofthe data packet. And, the header portion includes information needed toroute the data to a desired receiving station and to identify the orderof the data packet amongst a group of data packets. A conventional datapacket includes an RTP (Realtime Transport Protocol) header field, a UDPfield, and an IP (Internet Protocol) field. The RTP field includes atime stamp value which specifies the time when the voice data of thepacket is created. The time stamp is used at a receiving station tocorrect for delay fluctuation introduced during communication of thedata packet. The RTP field also includes a sequence number. The sequencenumber is used at a receiving station to detect packet loss andmis-sequencing of data packets. Values of the UDP and IP fields aregenerally of constant values for data packets generated within a singlecommunication session and identify the identities of the sending andreceiving stations.

Communication systems are usually bandwidth-constrained. That is to say,the bandwidth available to define communication channels and allocatedfor use in a communication system typically limit the communicationcapacity of the communication system. The communication capacity of thecommunication system can be increased only when the bandwidth allocatedto the communication system is used more efficiently. Constraints placedupon radio communication systems are oftentimes particularly acute asthe bandwidth allocated to a radio communication system is typicallylimited to a frequency region of the electromagnetic spectrum.

A problem associated with the use of packet-formatted data is therelatively high percentage of the bandwidth consumed by thecommunication of the header portions of all of the data packets.Communication of the voice information pursuant to a VoIP communicationservice is much less efficient than it otherwise would be if the headerportions of the data packets are removed.

To increase the efficiency of use of the bandwidth allocated upon theradio link, proposals have been set forth to provide manners by which toremove the header portions of the data packets prior to theircommunication upon the radio links formed between mobile stations andthe network infrastructure of the communication system.

More generally, communication networks transfer information such as uservoice traffic or the like, on a packet-switched and/or circuit-switchedbasis using modes which may be commanded by the system or negotiatedbetween the involved network elements such as end user equipments. As anexample, in evolved networks such as UMTS (Universal MobileTelecommunication System) systems, additional functions and services canbe incorporated. For instance, novel multimedia services such asmultimedia messaging services MMS are supported within the system whichservices are IP (Internet Protocol)-based services. Packet-based (e.g.IP-based) service sessions such as multimedia service sessions may becontrolled by a specific protocol. As an example, the Session InitiationProtocol (SIP) represents a protocol which may be used e.g. for call andconnection establishment as well as for transport of endpoint capabilityinformation. Such capability information may e.g. relate to voice andmultimedia codecs supported by the end terminals.

The functionality and services of such multimedia service systems willbe mapped onto the existing network system functions, e.g. of UMTS type.As an example, the system services may be mapped to the PDP contexts andradio signalling, as well as to existing packet-switched core networkelements and interfaces, e.g. of UMTS type. Hence, there is a problem ofmultimedia (e.g. IP multimedia) and network layer (e.g. GPRS layer)interactions and mapping.

As an example, in case of VoIP calls (voice over IP-based connection,i.e. Internet telephony), the radio access network such as GERAN(“GSM/Edge Radio Access Network”) and UTRAN (UMTS Terrestrial RadioAccess Network), may be informed on the type of application for decidingon the header adaptation method to be used for e.g. a particular PDPcontext. As an example, two different header adaptation schemesavailable for selection can for example be “header compression” and“header stripping/removal”. The header stripping/removal mode may beused for speech-only traffic where e.g. optimised speech transport isrequired for instance for integrated lower-end terminal devices. Aheader compression mode may be utilised e.g. for more general IPmultimedia traffic including voice application operation on an externaldevice such as a laptop computer connected to a UMTS phone.

When an inappropriate mode such as inappropriate protocol mode, headeradaptation mode or radio access bearer mode should be selected, problemsin incorrect message transmission may occur.

SUMMARY OF THE INVENTION

The invention provides a method and system as defined in anyone of theclaims.

In more detail, a communication system, and/or a method to be performedin a communication system, comprises at least one first network elementconnectable to a second network element via one or more packet-basednetworks. At least one of the first and second network elements providetwo or more selectable modes for communicating with another networkelement. A mode selection procedure is performed (e.g. by one or both ofthe network elements, or by a third network element connected to thefirst and second network elements), for selecting the same mode forbidirectional communication between the network elements. The selectablemodes preferably are different codec types, or may be conversion modesof other type, or radio interface protocol types or channel-codingschemes etc.

The first and/or second network elements may be portable terminalequipments. The third network element preferably is a support node orsupport function.

In a preferred embodiment, a protocol mainly used for other purposes butalso capable of providing a messaging service, preferably an IP-basedmultimedia messaging service, is used for sending information onsupported or selected modes to and from the network elements. Theprotocol may be the Session Initiation Protocol (SIP). SIP is amultimedia session establishment & control protocol, i.e. a controlprotocol for realtime multimedia.

Preferably, the network or networks connecting the first and secondnetwork elements is/are UMTS-based network.

In one embodiment, the first network element may send information on oneor more modes supported by the first network element to the thirdnetwork element which performs the selection procedure and sendsinformation on only one or more than one but not all supported modes tothe second network element which sends an acknowledgment message to thethird network element confirming the support of the selected, or one ofthe selected modes, the third network element sending a message to thefirst network element informing the latter on the selected mode. This isone difference between a preferred embodiment of the invention and theusual SIP operation. Usually there is no negotiation between the usedcodecs etc. but both elements include information on their owncapabilities in the SIP messages. Here, a selection and a specific usageof the information fields etc. is proposed.

In another embodiment, the first network element may send information onone or more modes supported by the first network element to the thirdnetwork element which requests the second network element to sendinformation on the supported modes, the second network element returninga list of supported modes to the third network element whereupon thethird network element performs the selection procedure and sendsmessages to the first and second network elements informing thesenetwork elements on the selected mode.

In a further embodiment, the first network element performs theselection procedure when initiating a connection to the second networkelement, and sends information on one mode supported by the firstnetwork element to the second network element. The second networkelement, when supporting the mode, returns an acknowledgment message,or, when not supporting the mode, returns a message indicating anothermode supported by the second network element, to the first networkelement. The first network element selects this mode for furthercommunication when supporting it, or, when the first network elementdoes not support the mode indicated by the second network element, theabove steps are repeated selecting another mode.

In a further embodiment, the first network element, when initiating aconnection to the second network element, sends information on all modessupported by the first network element to the second network element.The second network element performs the selection procedure and returnsa message indicating the selected mode to the first network element, thefirst and second network elements selecting the indicated mode forfurther communication.

The first network element and/or second network element and/or thirdnetwork element preferably send information on the selected mode to aradio network control means. The information on the selected protocolmode may e.g. be sent as part of a negotiation procedure related topacket data convergence protocol, or in an Activate PDP Context message.The information on the selected mode preferably contains an additionalflag indicating the application type. It is possible to send only theapplication type and no other information.

The information on the selected mode preferably contains additionalinformation on the header processing such as header compression orheader stripping/removal.

Generally, in accordance with the present invention, a selectionprocedure is provided for performing a mode selection, preferably whenestablishing a connection between two network elements. This modeselection such as protocol selection is ensuring that the bi-directionalcommunication between the network elements is performed in a definedmanner such as use of the same mode in uplink and downlink direction.

As an example, such a mode selection is able to ensure that e.g. theradio access bearers in an UMTS network use and support the same codectype (e.g. AMR (Adaptive Multi-Rate), GSM FR (Full Rate), GSM EFR(Enhanced Full Rate), etc.) at the same time, and use the same, i.e.only one, codec type in uplink and downlink directions. In some casessuch as AMR, there might otherwise be provided different codec modes inuplink and downlink direction. The codec information may be used toselect the appropriate radio interface protocol modes including anappropriate channel coding scheme for voice traffic.

The use of the same codec in both directions guarantees that the channelcoding for the corresponding radio bearer of a PDP (Packet DataProtocol) context is appropriately and correctly selected so as to bethe same in both directions. As at least one PDP context is necessaryfor carrying the voice traffic, an appropriate radio bearer is selectedso that UMTS IP telephony can be performed (VoIP) without problems.

An advantage of the invention is the possibility to enable e.g. SIPoperation on top of an UMTS radio access network architecture andbearers. Apart from the fact that the new information on selected modeand application type provided to the radio access network is already asort of change of the existing network architecture, no other changes ofexisting radio access networks such as UTRAN or GERAN for any actual orfuture definition such as 3GPP Release 2000 are necessary for solvingthe above mentioned problems. The invention therefore provides asolution for IP telephony on UMTS.

The solution according to the invention can be implemented as aproprietary mechanism or function, or can be a standardised mechanism orfunction.

In accordance with a further aspect of the invention, a network elementis provided, preferably to be used in a method or communication systemas described above, the network element being adapted to perform aselection procedure for selecting one of several modes supported by thisor another network element. The modes may be different conversion modes,in particular coding/decoding modes.

According to another aspect, the invention may provide a manner whichfacilitates signaling of whether the header portions of the data packetsare to be removed pursuant to effectuation of a communication service.Signaling is preferably provided between the mobile station and thenetwork infrastructure to identify when header portions of the datapackets are to be removed pursuant to effectuation of a communicationsession. The invention provides signaling of such information andadequately defines the manner by which to signal whether the headerportions of the data packets are to be removed. A QoS IE can be used forsuch a purpose, representing an example on how additional information onthe selected protocol can be expressed. This feature of headerstripping/removal can also be used independent of the other featuresmentioned in the description or claims.

In an embodiment, the invention provides an apparatus and method forinitiation of header-portion removal in a radio communication systemhaving a mobile station operable to communicate packet-switched datawith a correspondent node by way of network infrastructure, thepacket-switched data formatted into data packets, the data packetshaving header portions and payload portions. The header-portion removalfacilites the communication of the packet-switched data upon a radiolink formed between the mobile station and the network infrastructure.

A means or function, e.g. QoS (Quality of Service) information element(IE) message generator, is coupled to receive indications of selectionof a preference to communicate data without the header portions upon theradio link. A QoS information element message containing an indicationof the preference is generated.

Further aspects, advantages and details of the invention will bedescribed by referring to the attached drawings which disclose preferredembodiments of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows the basic structure of a first embodiment of the presentinvention;

FIG. 2 illustrates a second embodiment of the invention;

FIG. 3 shows another embodiment of the invention;

FIG. 4 illustrates a further embodiment of the invention;

FIG. 5 illustrates a functional block diagram of a communication systemin which an embodiment of the present invention is operable;

FIG. 6 illustrates a logical layer representation of portions of thecommunication system shown in FIG. 5, here representing packet headerremoval of packet headers from RTP (Real-Time TransportProtocol)-formatted data packets communicated during operation of thecommunication system;

FIG. 7 also illustrates a logical layer representation of portions ofthe communication system shown in FIG. 5, here representing headergeneration by which packet header information is added to data packetscommunicated during operation of the communication system;

FIG. 8 illustrates a message sequence diagram illustrating messagesgenerated during operation of the communication system shown in FIG. 5,including a message containing a QoS (quality of service) informationelement (IE) of an embodiment of the present invention; and

FIG. 9 illustrates representation of the QoS information elementincluding indicia indicating a preference of a header adaptationmechanism to be utilized pursuant to a communication session.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS OF THE INVENTION

Before describing some embodiments of the invention in more detail,several general aspects and features of the invention will be discussed.In connection set-up, some protocols such as the call establishmentprocedures of SIP (Session Initiation Protocol) allow negotiation andusage of several codecs from end-to-end, that is between the calloriginating element and the call terminating element. Further, suchprotocols may also allow the use of different codecs in uplink anddownlink directions. Due to the selection procedure performed inaccordance with a preferred aspect of the invention, IP telephonyapplications in networks such as UMTS of third generation type can beused on top of the UMTS radio access networks (RANs) without interferingwith the functionality of the system and with minimum changes of thesystem. Hence, correct functioning can be ensured also in such cases.

When using for instance SIP, the caller may send a set of supportedcodecs to the callee or to a third network element. The callee may alsosend a set of supported codecs to the caller or to the third networkelement. After the call-setup, when sending VoIP packets, the inventionmay be used to guarantee that the caller uses one of the codecssupported by the callee and the callee uses one of the codecs supportedby the caller, and that these used codecs are the same for the calleeand the caller. Otherwise, when not performing a mode selectionprocedure for selecting e.g. only one and the same codec for thebidirectional communication, the sender might dynamically select a codecfrom the set of codecs supported by the recipient when sending data tothe latter so that different codecs might eventually be used.Furthermore, the used codec might be different in different directions.

In accordance with preferred implementations of the invention, severalalternatives are disclosed. According to one aspect, a terminalequipment (network element), e.g. a UMTS phone, or the network, e.g. theUMTS network, functions so as to ensure that always only one codec typeis used in each direction, and further that this codec type is the samein both directions. This may be achieved in one or both terminalequipments such as UMTS terminals by mandating support for specificcodec(s) in all cases and/or by defining that only one codec can beannounced to the other endpoint as supported codec.

Furthermore, the behaviour of the callee is defined and adapted in sucha manner that the call terminating equipment selects, if possible, thesame codec as the one announced by the call originating equipment. Incase of failure of the call terminating equipment in selecting the samecodec as the one announced by the call originating equipment, the callterminating equipment is preferably adapted to select a codec which ismandatory in systems of the third generation (3G systems), and toannounce this codec to the call originating equipment. The calloriginating equipment will support the announced codec as it is amandatory one, and is adapted to assume at this point that the callterminating equipment will use the same codec also in sending data, andwill therefore adjust its behaviour accordingly.

In accordance with another alternative embodiment of the invention, afurther solution is provided. In the network such as the UMTS network, acontrol means (third network element) will decide on the codec to beused and will handle the selection procedure and the necessary messagesto be sent to the call originating and terminating equipments. Thiscontrol means may e.g. be the CSCF (Call State Control Function) of thenetwork and/or may e.g. be the proxy CSCF in the visited network such asPLMN (Public Land Mobile Network) in case of a roaming subscriber,and/or the home CSCF in the home network e.g. PLMN of the subscriber.

The control means can render the decision on the codec to be used byboth the call originating and terminating equipments. In preferredimplementation, the codecs supported by the call originating equipmentare included in a specific message such as the Invite message of SIP.After receiving the Invite message, the control means such as CSCF canselect one of the codecs, i.e. perform the mode selection procedure, andcan modify the Invite message so as to include only the selected codecbefore forwarding the Invite message to the call terminating equipment.The call terminating equipment is adapted to acknowledge receipt theInvite message by sending an acknowledgement message such as 200 OKmessage of SIP, only if it supports the single codec indicated in theInvite message as selected by the control means. It is possible to sendan acknowledgement message also in the negative case, e.g., givingnegative acknowledge or including the supported codecs by the callterminating equipment.)

The selection procedure performed in the control means such as CSCF maybe based e.g. on the operator preferences. As an example, when theoperator prefers to use AMR, the selection procedure is adapted toselect AMR from a set including FR, HR and AMR. Another example is acase when a transcoder pool is used. In such a case, the operator mayoptimise the usage of the transcoders. In the latter case, the decisionand selection is preferably made in a control means of the visitednetwork, that is in a visited network element such as e.g. in the proxyCSCF.

Furthermore, location information of the user may be taken into accountwhen deciding on the coded to be used. For example, if the base stationsubsystems (BSSs) in different parts of the network/country are e.g.based on different product releases and for this or other reasons preferdifferent codecs, or for reasons of transcoder pool optimisation, thecodec selection procedure may be adapted to take account of suchparameters.

A further alternative approach implemented in another embodiment of theinvention is the selection of the codec by a control network elementsuch as CSCF after having received information on all codecs supportedby the call originating equipment (e.g. in an Invite message) and on allcodecs supported by the call terminating equipment (e.g. in the 200 OKmessage of SIP). After having received both the messages, the controlmeans knows both codec sets supported by the call originating equipmentas well as by the call terminating equipment. The control means thenperforms the mode selection step by selecting one codec supported byboth call originating and terminating equipments either by arbitrarilyor by reference to a priority list ranking the codecs according to thepriority assigned by e.g. the network operator or service provider.

After selecting the codec to be used by both call originating andterminating equipments, the selected codec is sent to the calloriginating equipment in a further message such as a 200 OK message ofSIP generated by modifying the 200 OK message received from the callterminating equipment, and to the call terminating equipment in anothermessage such as a ACK message of SIP.

When the codec to be used has been selected, one or more networkelements, in particular control elements such as the radio networkcontrollers or base station subsystems controlling the radio access tothe call originating and/or call terminating equipment have to beinformed on the selected codec. This informing of the network controlelements can be performed in several alternative ways which are listedbelow in the preferred order.

-   -   1.) The call originating and/or terminating equipment such as a        mobile station (MS) sends information on the selected codec to        the radio access controller (e.g. RNC, Radio Network Controller)        as part of the PDCP (Packet Data Convergence Protocol)        negotiation. The messages sent to the control element informing        the same about the selected codec may additionally include a        separate flag or other indication to indicate the application        type, and/or whether to use header compression or header        stripping/removal for this particular PDP context.    -   2.) As an alternative, the call originating and/or terminating        equipment sends the information on the selected codec to the        serving node such as SGSN (Serving GPRS Support Node). The        serving node forwards the information on the selected codec to        the control element such as RNC in the RAB (Radio Access Bearer)        establishment request message. The transmitted message(s) may        additionally include further information such as a flag to        indicate the application type, and/or whether to use header        compression or stripping/removal for a particular PDP context.    -   3.) The call state controlling means such as CSCF may send        information on the selected codec to the radio access control        means such as RNC (e.g. in the following manner: CSCF−>GGSN        (Gateway GPRS Support Node), GGSN−>SGSN, SGSN−>RNC). As already        stated above, the messages may also include a separate        indication such as a flag to indicate the application type,        and/or whether to use header compression or stripping/removal        for the particular PDP context.

When an application type indication (e.g. application type flag) isincluded, the information on the application type is transmitted fromthe call originating or terminating equipment (e.g. Mobile Station MS)or from the call control means (e.g. CSCF) because these entities are,in an UMTS network, the only entities having enough information aboutthe services and applications running on top of the PDP contexts. Theheader compression is preferably set as the default operation if theapplication type is not known or indicated in the message. The headerstripping/removal is preferably used for optimised speech transmissionwhen only voice traffic is carried in the PDP context.

The necessary application information is preferably received throughinternal application programming interfaces (APIs) of the calloriginating and/or terminating equipments (the. internal APIs beingarranged between the applications/services), the SIP layer and theUMTS/GPRS layers. Header stripping/removal is preferably used only inthe case of an integrated UMTS SIP terminal. It may also be providedfrom a laptop computer to a UMTS phone in a case where the terminalequipment (TE) and the call originating and/or terminating equipmentsare separate devices. The application type indication such as a flag mayfor example have the following explicit values: “header compression”, or“header stripping/removal”, or “application type” (e.g. value: voice)which indicates that stripping/removal is to be used.

In the following, details of a first embodiment will be described withreference to FIG. 1. FIG. 1 shows a terminal network element 1 which istermed “UE (User Equipment) Caller” and requests the establishment of aconnection to another network element 3. The network element 3 thusrepresents a call terminating equipment and is termed “UE Callee”. Thenetwork comprises a further network element 2 which is a connectioncontrol element and is implemented as, or provides, a call state controlfunction (CSCF). When the network element 1 such as a MS (MobileStation) desires to establish a connection to the terminal networkelement 3, it is adapted to send, in this embodiment, a message to theCSCF 2 informing the latter on the desire to establish a connection tothe terminal equipment element 3 which message contains information onall codecs supported by the network element 1, i.e. the call originatingequipment. This message may be an Invite message of the connectionprotocol, preferably SIP. This Invite message contains a list of codecssupported by network element 1.

The CSCF element 2 is adapted to perform a mode selection procedurewhich, in this embodiment, is a codec selection procedure 4 selectingone of the codecs supported by equipment 1. This codec selection 4 maybe based on preference or priority parameters contained in CSCF 2, ormay be dependent from the type of application desired by equipment 1such as pure data transmission, pure voice over IP transmission, and thelike.

After performing the codec selection procedure 4, the CSCF 2 furthertransmits the Invite message to the user equipment 3, the message nowonly including the codec selected by the codec selection procedure 4.The user equipment 3 which may likewise be a mobile station orstationary equipment, performs an internal check whether it supports thecodec indicated in the received Invite message 9. If yes, the userequipment 3 returns an acknowledgment message to the CSCF 2 (preferablya 200 OK message in SIP) which message repeats the selected codec forconfirmation of its support by user equipment 3. The CSCF 2 transmitsthis acknowledgment message to the user equipment 1 (200 OK (selectedcodec)) in SIP.

When receiving this message, the user equipment 1 is adapted to use onlythis indicated codec for uplink and downlink links. In a similar manner,user equipment 3 is adapted to use only the selected codec for uplinkand downlink traffic, i.e. for radio access between user equipment 3 andthe radio access controlling means such as RCP (Radio NetworkController). The radio network controllers handling the radio access tothe user equipments 1 and 3 will likewise be informed on the selectedcodec using one of the above-mentioned methods as an example, and willadapt their operation mode accordingly.

When the user equipment 3 should not support the selected codecindicated in the Invite message received from CSCF 2, it is preferablyadapted to send a message to CSCF 2 informing the latter on lack ofsupport of the selected codec. Thereupon, the CSCF 2 repeats the codecselection procedure 4 but now selecting another codec different from thefirst selected codec, and sends this newly selected codec in a messagesuch as an Invite message to user equipment 3. When this codec issupported by user equipment 3, it returns the 200 OK message, otherwisethe above steps are repeated until a codec is selected which issupported by the user equipment 3

FIG. 2 shows another embodiment of the invention wherein the codecselection procedure 4 is performed, similar as in the first embodiment,by CSCF 2. Contrary to the above discussed first embodiment, the CSCF 2requests, after receipt of an Invite message indicating all or at leastsome of the codecs supported by the user equipment 1, the user equipment3 to return information on all codecs supported by user equipment 3.This message may be an Invite message of SIP defining a request forreturning a list of supported codecs. The user equipment 3 returns amessage (e.g. 200 OK message of SIP) which contains a list of codecssupported by user equipment 3.

This list may contain all codecs supported by user equipment 3, or mayindicate only those codecs which are also supported by the userequipment 1. In the latter case, the user equipment 3 receives, in theInvite message from CSCF 2, a list of the codecs supported by the userequipment 1, and is adapted to perform a comparison of codecs supportedby user equipment 1 and codecs supported by user equipment 3, selectingonly those codecs which are supported by both user equipments 1 and 3.In the former case in which the list returned by the user equipment 3includes all supported codecs, the Invite message sent from CSCF 2 tothe user equipment 3 may not contain any indication of codecs supportedby user equipment 1.

The CSCF 2 selects, by the codec selection procedure 4, one of thecodecs supported by both user equipments 1 and 3, and then sendsmessages to both user equipments 1 and 3 informing them on the selectedcodec for use thereof during the subsequent connection. The messageaddressed to user equipment 1 may be a message 200 OK of SIP indicatingthe selected codec. The user equipment 1 may return an acknowledgementmessage to the CSCF 2 acknowledging the receipt of the 200 OK messageand eventually repeating the selected codec. The CSCF 2 may forward theacknowledgement message received from user equipment 1 to user equipment3 after adding (if not already included) an information indicating theselected codec.

The embodiment of FIG. 2 contributes to a very quick selection of acodec supported by both user equipments.

All explanations, features and advantages stated above with regard tothe first embodiment are also applicable with regard to this secondembodiment (unless being in contradiction to the above explanations),and also for the subsequently discussed embodiments 3 and 4.

The embodiment shown in FIG. 3 is different from the above discussedfirst and second embodiment in that the codec selection procedure 4 isperformed by and in the user equipment 1. After having performed thecodec selection depending on the intended application (voicetransmission, non-real-time traffic or the like, or depending on otherparameters, the user equipment 1 sends a message such as an Invitemessage to the user equipment 3 via the CSCF 2, indicating the selectedcodec. The user equipment 3, when supporting the selected codec,returns, via CSCF 2, an acknowledgement message which may be a 200 OKmessage indicating the selected supported codec.

In case user equipment 3 does not support the selected codec, therepetition of the codec selection procedure 4 including the transmissionof the related messaging, is repeated, as already stated above withregard to the first embodiment (with the exception that the codeselection procedure 4 is repeated in the user equipment 1 and not in theCSCF 2. All other explanations given above with regard to the first andsecond embodiments likewise apply to this third embodiment.

FIG. 4 illustrates a fourth embodiment wherein the codec selectionprocedure 4 is performed in the user equipment 3. In this case, the userequipment 1 sends a message, via CSCF 2, to the user equipment 3indicating all codecs supported by user equipment 1. This message may bean Invite message of SIP. After having received information on thecodecs supported by user equipment 1, the user equipment 3 performs thecodec selection procedure 4 by selecting, from the list of codecssupported by user equipment 1, one of the codecs which is also supportedby user equipment 3. After having performed the codec selectionprocedure 4, the user equipment 3 sends a message to the user equipment1, via the CSCF 2, informing user equipment 1 and eventually also CSCF2, on the selected codec. The selected codec is thereafter used by bothuser equipments 1 and 3. All other explanations given above with regardto the first to third embodiment likewise apply to the present fourthembodiment.

As shown in FIG. 4 (the procedure shown in FIG. 4 is preferably commonto all the earlier embodiments of the invention), a radio accesscontroller such as RNC 5 being in charge of radio access control to userequipment 1 is informed by user equipment 1 on the selected codec, andpreferably also on the application type by sending an application typeflag indicating e.g. “header compression” or “header stripping/removal”.This information can be sent when performing the PDCP negotiation 6 butmay also be sent in a separate message. In a similar manner, the userequipment 3 informs its radio access control element such as RNC 7 beingin charge of radio access control to user equipment 3 by sending amessage 8 to RNC 7. This message indicates the selected codec and mayalso contain, if known, an application type flag.

This informing of the radio access control elements 5 and 7 in charge ofthe radio access to and from the user equipments 1 and 3, respectively,is likewise applicable to all above described first to third embodimentsin identical manner.

The following embodiments of the invention relate generally toapparatus, and associated method, for initiating header removal ofpacket data communicated upon a radio link a manner by which tofacilitate initiation of header removal procedures in packet-switchedcommunications effectuated by way of a radio link, such as VoIP (Voiceover Internet Protocol) communications in a 3G (third generation)cellular communication system effectuated pursuant to a communicationsession. More particularly, the embodiments relate to an apparatus, andan associated method, by which to generate a message selectablyindicating a preference to remove the packet headers preliminary toeffectuation of the communication session. In a Quality of ServiceInformation Element (QoS IE), e.g. proposed for use in a 3G GSM/EDGE(Global System for Mobile Communications/Enhanced Data for GlobalEvolution) system, a header adaptation field is defined in an availablesection, e.g. octet. Values of the bits formed in the header adaptationfield are selected to indicate whether the header portions are to beremoved.

Generally, communication technologies permit the introduction, andpopular usage, of new types of communication systems resulting, forexample, in significant increases in the rates of data transmission. Theincreased data transmission rates allow for new types of communicationservices.

The embodiments of the invention, accordingly, advantageously provideapparatus, and associated method, by which to facilitate initiation ofheader removal procedures in packet-switched communications effectuatedby way of a radio link, such as a VoIP (Voice over Internet Protocol)communications in a 3G (third generation) cellular communication systemeffectuated pursuant to a communication session.

Through operation of an embodiment of the present invention, a messageis generated indicating a preference whether to remove the packetheaders preliminary to effectuation of the communication session. In aQuality of Service Information Element (QoS IE) proposed for use in a 3GGSM/EDGE (Global System for Mobile Communications/Enhanced Data forGlobal Evolution) system, a header adaptation field is defined in anavailable octet. Values of the bits formed in the header adaptationfield are selected to indicate whether the header portions are to beremoved.

In one aspect of the present invention, a header adaptation field isprovided for a QoS (Quality of Service) information element communicatedby a mobile station to the radio access network(RAN) portion of a radiocommunication system. The header adaptation field is selectably ofvalues to initiate removal of the header portions of data packets to becommunicated pursuant to a communication session, such as a VoIP (voiceover internet protocol) communication session between the mobile stationand another communication endpoint, such as a VoIP terminal connected toa packet data network.

In another aspect of the invention, a manner is provided by which toinitiate, at a mobile station operable in a packet radio communicationsystem a VoIP, or other, packet-based communication session in whichheader information is to be removed from the data packets prior to theircommunication upon a radio link formed with the mobile station. Headeradaptation indicia is sent by the mobile station to a radio accessnetwork portion of the communication system pursuant to sessioninitiation. The header adaptation indicia is of values indicating apreference to remove the header information during communication of thepacket data to effectuate the communication session.

In one implementation, the header adaptation indicia is contained in aheader adaptation field forming a portion of a QoS information element,formed generally pursuant to the 3 GPP standard promulgation, section24.008 v4.1.1. The QoS information element is sent by user equipment,such as a mobile station as part of an active PDP (packet data protocol)request message, as part of communication session setup procedures. Byremoving the header portions of the data packets communicated upon aradio link during the communication with the user equipment, additionalamounts of the limited available bandwidth of the radio link is madeavailable for use to effectuate communication of non-overheadinformation.

A manner is thereby provided by which to initiate header removal of datapackets communicated upon a radio link. Header removal is targetedprimarily to the support of IP-based optimized speech in a cellularnetwork. In order to permit a radio resource controller of a radioaccess network portion of the network to be able to decide whetherheader removal is applicable, signaling must be provided, either by acore network to which the radio access network portion is connected orby the mobile station. Operation of an embodiment of the presentinvention provides such signaling.

In these and other aspects, therefore, apparatus, and associated method,is provided for a communication system having a mobile station operableto communicate packet-switched data with a correspondent node, by way ofnetwork infrastructure. The packet-switched data is formatted into datapackets which have header portions and payload portions. Header-portionremoval is initiated to facilitate communication of the packet-switcheddata upon a radio link formed between the mobile station and the networkinfrastructure. A QoS (Quality of Service) information element (IE)message generator is coupled to receive indications of selection of apreference to communicate data packets without the header portions uponthe radio link. The QoS information element message generator generatesa QoS information element message containing an indication of thepreference.

A more complete appreciation of these embodiments can be obtained fromthe accompanying drawings and the following detailed description of theembodiments.

Referring first to FIG. 5, a communication system, shown generally as10, provides for radio communication with a mobile station 12. Here,communications are effectuated pursuant to a communication sessionbetween the mobile station and a correspondent node 14. A communicationpath is formable between the correspondent node and the mobile station.The communication path is defined upon a radio link 16, elements of abase station system and radio access network (BSS/RAN) portion 18, anSGSN (Serving GPRS Service Node) 22, a GGSN (Gateway GPRS Service Node24, and a packet data network backbone, here an IP (Internet Protocol)network 26.

The radio access network portion 18 includes network elements operableto permit the radio connection with the mobile station upon the radiolink 16. In the exemplary implementation, the radio access networkportion is generally constructed to be operable pursuant to a proposedGERAN (GSM/EDGE Radio Access Network), as presently promulgated.

The SGSN 22 and the BSS/GERAN 18 are interfaced by an Iu interface,analogous to a UTRAN interface. Separately, the radio access networkportion is connectable to a 2G (second generation) packet switched corenetwork by way of a Gb interface or, for instance, a 2G mobile switchingcenter (MSC) by way of an A interface.

In exemplary operation in which data originated at the mobile station iscommunicated to the correspondent node, the mobile station forms thesending station. And, the correspondent node which receives the dataforms the receiving station. As two-way communications are effectuablebetween the mobile station and the correspondent node, the correspondentnode also forms a sending station, and the mobile station also forms areceiving station. Description of operation of an embodiment of thepresent invention can analogously be described with respect tocommunication of data by the correspondent node to the mobile station.

The communication session here forms, e.g., a voice-over internetprotocol (VoIP) communication session. Speech transmission over thepacket-switched network of which the communication system 10 is formedis realized through the use of RTP (real-time transmissionprotocol)-formatted packets. RTP packets are further encapsulated into auser data protocol (UDP) and internet protocol (IP) packets.Packet-switched speech transmission is generally referred to asvoice-over IP (VoIP). The RTP control protocol (RTCP) is defined in theRTP specification. RTCP is used to monitor quality of service (QoS) andto give information about the participants of a communication session.RTCP packets are transmitted periodically, less often than transmissionof RTP packets to limit the bandwidth consumptive RTCP traffic.

Packet-switched speech communications, such as pursuant to VoIPcommunications, enables an increase in the effective use of radiocapacity, and, hence, connectivity between the mobile station and thecorrespondent node. Present proposals for the packet-switched speechtransmission makes use of SIP/SDP for call control and RTP/RTCPprotocols for the transmission of speech data, also in the 3G network.

FIG. 6 illustrates the communication system 10 in logical-layer form,here showing the mobile station 12 and the GERAN portion 18. The mobilestation is shown to include an PDCP layer 52 positioned upon an RLClayer 54. The RLC layer 54, in turn, is positioned upon a MAC layer 56.And, the MAC layer is positioned upon a lower layer, L1, 58.Analogously, the GERAN portion 18 includes corresponding layers, herethe PDCP layer 62, an RLC layer 64, a MAC layer 56, and a lower layerL1, 68. The radio link 16 is also shown in FIG. 6. Here, the RTP/UDP/IPheaders 72, here shown to be followed by a voice frame 74, is routed tothe radio access network portion 18. The headers are removed at theradio access network portion. Effectively, through the removal of theheader information, the RTP/UDP/IP protocol end-point is within thenetwork. And, the radio access network 18 acts as a proxy server for theuser-plane traffic RTP. In the control plane, i.e., the planes 52 and 62in FIG. 6, SIP/SDP terminates at the mobile station 12.

FIG. 7 again illustrates the mobile station 12 and the radio accessnetwork portion 18 in logical-layer form. The mobile station is shown tobe formed of the layers 52, 54, 56, and 58. And, the radio accessnetwork portion is again shown to be formed of the layers 62, 64, 66,and 68. Here, a voice frame 74, originated at the mobile station, isrouted upon the radio link to the radio access network portion. Once thevoice frame is received at the radio access network portion, theRTP/UDP/IP header information 72 is added to the voice frame to permitrouting through the network to the correspondent node.

FIG. 8 illustrates a message sequence diagram, shown generally at 82,showing certain of the messages generated during operation of thecommunication system 10 shown in FIGS. 5 to 7. The messages aregenerated pursuant to formation of a communication session between themobile station 12, represented in FIG. 8 by the commonly-referenced userequipment block, and the correspondent node 14, indicated in FIG. 8 bythe commonly-referenced CSCF (Call State Control Function). The CSCF isan SIP proxy, and the functionality thereof is defined by 3 GPP.

First, and as indicated by the segment 84, initiation of communicationsession set up is started. SIP signaling is utilized to set up thesession, and the mobile station/user equipment is here the entity whichknows the type of application which is to be used during thecommunication session.

The message indicated by the segment 84 forms an SIP Invite message. TheInvite message asks a callee, here the correspondent node/CSCF to join aparticular conference or establish a two-party conversation forming acommunication session. The Invite message typically contains a sessiondescription, e.g., written in SDP format, that provides the called partywith enough information to join the session. For multicast sessions, thesession description enumerates the media types and formats that arepermitted to be distributed to that session. For a unicast session, thesession description enumerates the media types and formats that thecaller is willing to use and where the caller wishes the media data tobe sent. In either case, if the callee wishes to accept the call, itresponds to the invitation by returning a similar description listingthe media it wishes to use. For a multicast session, the callee shouldonly return a session description if the callee is unable to receive themedia indicated in the description of the caller or if the callee wants,instead, to receive data via a unicast session.

The message, indicated by the segment 86, is representative of such aresponse or an ACK (Acknowledge) indication returned to the mobilestation. And, a final SDP message, sent by the mobile station/userequipment to the correspondent node/CSDF, is indicated by the segment88. Additional details related to SIP signaling are set forth in the 3GPP ETS 23.228 and 24.228. Once both endpoints of the proposedcommunication session have agreed to the communication sessiondescription, the mobile station/user equipment activates a PDP (PacketData Protocol). An activate (secondary) PDP context request, indicatedby the segment 92, is sent by the mobile station/user equipment to theSGSN 22. The request includes a QoS (quality of service) informationelement (IE). When, as here, the communication session is to be a VoIPcommunication session with optimized speech, i.e., with packet-dataheader removal, the QoS information element includes an indication ofthe preference to remove the RTP/UDP/IP headers from the data packetsprior to their communication upon the radio link.

Responsive to the request, the SGSN generates a radio access bearerassignment request, indicated by the segment 94, and sends the requestto the BSS/RAN 18. The radio access bearer assignment request, in theexemplary implementation, corresponds generally in value and structurewith the request set forth in 3 GPP 25.413 and includes headeradaptation field of an embodiment of the present invention as a portionthereof. The SGSN alternately can use a predefined QoS parametercombination in the radio access bearer message, thereby to provideunambiguous information to the GERAN that header removal can beutilized.

When the BSS/GERAN receives the radio access bearer assignment message,a header adaptation mechanism algorithm at the BSS/RAN is used to choosea header adaptation mechanism. And, thereafter, the BSS/GERAN generatesa radio bearer setup message, indicated by the segment 96, forcommunication upon the radio link to the mobile station/user equipmentto inform the mobile station/user equipment of the selections madethereat. The BSS/RAN also generates a radio access bearer response,indicated by the segment 98, which is returned to the SGSN 22.

Thereafter, and as indicated by the segment 102, an activate (secondary)PDP context accept message is generated by the SGSN. The message issent, by way of the BSS/RAN and the radio link, to the mobilestation/user equipment.

FIG. 9 illustrates a QoS information element, shown generally at 108,which forms a portion of the activate (secondary) PDP context request,identified by the segment 92 in FIG. 8. The QoS information elementgenerally corresponds in format to the format set forth in the 3 GPP ETS24.008 v4.1.1 and is structured to include fourteen octets. The octetsare numbered in the FIG. as octets 1 through 14. Each octet is of aneight bit length.

The first octet, octet 1, is formed of an eight-bit Quality of ServiceIEI field 112. The second octet, octet 2, is formed an eight-bit lengthof quality of service IE field 114. And, the third octet, octet 3, isformed of a two-bit 0 spare field 116, a three-bit delay class field118, and a three-bit reliability class field 122.

The fourth octet, octet 4, includes a four-bit peak throughput field124, a single-bit spare field 126, and a three-bit precedence classfield 128. The fifth octet, octet 5, includes a three-bit spare field132 and a five-bit mean throughput field 134. The sixth octet, octet 6,includes a three-bit traffic class field 136, a two-bit delivery orderfield 138, and a three-bit delivery of erroneous SDU field 142. And, theseventh octet, octet 7, forms an eight-bit maximum SDU size field 144.

The eighth and ninth octets, octet 8 and octet 9, also form singleeight-bit fields. The eighth octet forms a maximum bit rate for uplinkfield 146, and the ninth octet forms a maximum bit rate for downlinkfield 148.

The tenth octet, octet 10, forms a four-bit residual BER field 152 and afour-bit SDU error ratio field 154. The eleventh octet, octet 11, formsa six-bit transfer delay field 158 and a two-bit traffic handlingpriority field 162.

The twelfth octet, octet 12, forms an eight-bit guaranteed bit rate foruplink field 164. And, the thirteenth octet, octet 13, forms aguaranteed bit rate for downlink field 166. The fourteenth octet, octet14 forms a new octet and field pursuant to an embodiment of the presentinvention. The octet includes a six-bit spare field 168 and a two-bitheader adaptation field 172.

The header adaptation field is of values to identify whether headerremoval of the header portions of the data packets to be communicatedupon the radio link during a communication are to be removed. Viz., thevalues of the bits which populate the header adaptation field indicatethe preference of whether the header portions of the data packets are tobe removed prior to their communication upon the radio link. When, asdescribed above, the communication session is to be a VoIP session, theheader portions are removed and the values of the header adaptationfield are selected to initiate their removal.

As the two-bit length of the header adaptation field permits fourpossible combinations of digital values, one of the digital values is aspare combination. Another combination, defines a no header adaptationpreference. And additional combinations define a header removalpreference and a header removal not possible indication. For instance,in the exemplary implementation, logical values “00” placed in theheader adaptation field indicate a no header adaptation preference.Logical values of “01” placed in the header adaptation field indicate aheader removal preference; logical values of “10” placed in the headeradaptation field indicate a header removal not possible indication, andlogical values of “11” placed in the header adaptation field are a sparecombination.

Thereby, a new header adaptation field formed in the QoS informationelement defined pursuant to proposals for set forth for a 3 GPP systemprovides a manner by which to facilitate selection of removal of theheader portions of data packets prior to their communication upon aradio link. Improved communication capacity in the communication systemis thereby possible.

The previous descriptions are of preferred examples for implementing theinvention, and the scope of the invention should not necessarily belimited by this description. The scope of the present invention alsocovers all modifications, amendments, additions and deletions offeatures within the abilities of a skilled man. As an example, the modeselection procedure has been described with reference to the codecselection but may also consist in a conversion modes selection of othertype, a protocol selection procedure or the like.

1. An apparatus for initiation of header-portion removal in a radiocommunication system comprising a mobile station operable to communicatepacket-switched data with a correspondent node by way of networkinfrastructure, the packet-switched data formatted into data packets,the data packets having header portions and payload portions, theheader-portion removal facilitating communication of the packet-switcheddata upon a radio link formed between the mobile station and the networkinfrastructure, said apparatus comprising: a quality of serviceinformation element message generator coupled to receive indications ofselection of a preference to communicate data without the headerportions upon the radio link, said quality of service informationelement message generator for generating a quality of serviceinformation element message containing an indication of the preference,wherein the quality of service information message element includes aheader adaptation field and wherein the indication of the preference iscontained in the header adaptation field, and wherein the quality ofservice information element message comprises a plurality of octets andwherein the header adaptation field is formed in a final octet of thequality of service information element message.
 2. The apparatus ofclaim 1, wherein said quality of service information element messagegenerator is positioned at the mobile station.
 3. The apparatus of claim1, wherein the quality of service information element defines aplurality of fields and wherein the indication of the preference iscontained in a selected field of the plurality of fields.
 4. Theapparatus of claim 3, wherein the radio communication system comprises a

third generation

cellular communication system, wherein the correspondent node comprisesa voice over internet protocol terminal and the packet-switched datacomprises voice over internet protocol data for effectuating a voiceover internet protocol communication session, and wherein the quality ofservice information element message generated by said quality of serviceinformation element message generator is generated prior to the voiceover internet protocol communication session.
 5. The apparatus of claim4, wherein the indication of the preference contained in the selectedfield is contained in a field appended to, and forming a portion of, themessage.
 6. The apparatus of claim 5, wherein the quality of serviceinformation element message generated by said quality of serviceinformation message generator is defined generally pursuant to a thirdgeneration partnership project European telecommunication standard,section 24.008 v4.1.1 promulgation.
 7. The apparatus of claim 1, whereinthe quality of service information element comprises fourteen octets andwherein the header adaptation field is contained in the fourteenth octetof the quality of service information element.
 8. The apparatus of claim1, wherein the header adaptation field is of a two-bit length.
 9. Amethod for initiation of header-portion removal in a radio communicationsystem, said method comprising: selecting a preference whether tocommunicate data packets without the header portions on a radio link,wherein the radio communication system comprises a mobile stationoperable to communicate packet-switched data with a correspondent nodeby way of network infrastructure, the packet-switched data formattedinto data packets, the data packets comprising header portions andpayload portions, the header-portion removal facilitating communicationof the packet-switched data upon the radio link formed between themobile station and the network infrastructure; and generating a qualityof service information element message containing an indication of thepreference, wherein the quality of service information message elementincludes a header adaptation field and wherein the indication of thepreference is contained in the header adaptation field, and wherein thequality of service information element message comprises a plurality ofoctets and wherein the header adaptation field is formed in a finaloctet of the quality of service information element message.
 10. Themethod of claim 9, wherein said selecting and generating are performedat the mobile station, and said method further comprising: sending thequality of service information element message upon the radio link.